Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:

1.Поддержка NVMe over TCP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.

2. Увеличение числа хостов на один датастор

У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.

3. Affinity 3.0 и поддержка CNS

В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.

4. Пакетные снапшоты томов vVols

В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.

Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.

Компания VMware перед предстоящей конференцией VMworld 2021 анонсировала скорую доступность для загрузки обновления своей главной серверной платформы виртуализации VMware vSphere 7 Update 3.

Нововведения будут сосредоточены в 3 основных областях:

Deliver AI and Developer-Ready Infrastructure

В новой версии vSphere была улучшена служба для развертывания виртуальных машин через стандартные Kubernetes API Virtual Machine (VM) Service, которая появилась в vSphere 7 Update 2a. Теперь администраторы и DevOps смогут использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Это позволит клиентам самостоятельно запускать AI-нагрузки в виртуальных машинах и просто работать с ними всем участникам процесса обслуживания виртуальной инфраструктуры.

Также было улучшено решение VMware vSphere with VMware Tanzu, которое теперь проще настраивать, особенно в части сетевого взаимодействия, на что ранее жаловались пользователи.

Создать тестовую лабораторию Kubernetes администраторам vSphere теперь стало гораздо легче.

Scale without Compromise

В этой категории улучшений больше всего изменилось в плане поддержки высокопроизводительной памяти Persistent Memory. Например, ее часто используют для таких нагрузок, как SAP HANA. Теперь в vSphere 7 Update 3 есть множество новых инструментов для анализа и настройки производительности памяти с точки зрения пропускной способности (bandwidth) и нагрузки. В дополнение к этому, теперь можно настраивать алармы на базе SLA и изменять конфигурацию машин и платформы на базе рекомендаций от механизма аналитики.

Также, поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Подробнее об этом рассказано здесь.

Simplify Operations

В новой версии vSphere 7 Update 3 появился специальный vCenter Server plug-in for NSX, который позволяет администраторам гораздо быстрее и удобнее настраивать сетевое взаимодействие и безопасность для NSX прямо из vSphere Client, без необходимости использования NSX Manager. В этой категории также появился простой процесс развертывания и настройки NSX-T, а также бесшовная аутентификация пользователей между vSphere и NSX-T.

Также механизм vSphere Distributed Resource Scheduler (DRS) теперь работает умнее в плане обработки операций обслуживания. Большие и более критичные нагрузки теперь перемещаются первыми и как можно скорее, чтобы пользователи не почувствовали никакого влияния процесса миграции во время обслуживания и апгрейда серверов.

Скачать апдейт VMware vSphere 7 Update 3, который выйдет на днях, можно будет по этой ссылке. Более подробно о новых возможностях обновления также рассказано вот в этой статье.

Давно мы не писали о продуктах компании NAKIVO - одного из лидеров в сфере резервного копирования и защиты данных виртуальной инфраструктуры. Недавно компания выпустила обновление NAKIVO Backup & Replication v10.4. Напомним, что мы писали о версии NAKIVO B&R 10 чуть больше года назад. С тех пор функциональность продукта существенно улучшилась - это полноценное Enterprise-решение, которое получило функции защиты от программ-вымогателей и...

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

Компания VMware выпустила обновление главного фреймворка для управления виртуальной инфраструктурой с помощью командных сценариев - PowerCLI 12.4. Напомним, что в прошлый раз об обновлении этой платформы мы писали вот тут. В обновленной версии PowerCLI появилось несколько новых возможностей:

1. Новый API интерфейс - RestAPI

Раньше PowerCLI имел 2 основных пути коммуникации с vSphere API:

• Get-View (SOAP API bindings)
• Get-CISService (JSON-RPC)

Теперь новые PowerCLI API байндинги позволяют работать vSphere REST API и предоставляют практически нативный интерфейс PowerShell.

Модуль, реализующий эти функции, называется vSphere Automation API SDK. Чтобы начать использовать новые возможности через автоматизацию REST API, нужно скачать новую версию PowerCLI - пакет будет называться "VMware.Sdk.vSphere". Он содержит в себе субмодули для взаимодействия со всеми REST API, которые есть в VMware vSphere.

В REST API есть методы для исполнения API и работы со структурами данных, которые используются как входные параметры для API. Новые API байндинги предоставляют низкоуровневые PowerShell функции для работы со всеми этими методами и структурами.

Функция Invoke используется для исполнения методов REST, таких как GET/PUT/POST и DELETE:

Функция Initialize используется для создания структуры данных, которая будет передана к REST API. Например, так выглядит создание структуры "локальный аккаунт":

$LocalAccountsConfig = Initialize-LocalAccountsConfig -Password 'Tes$TPa$$w0Rd' -Roles 'superAdmin' #Create Account Config

$LocalAccountsCreateRequestBody = Initialize-LocalAccountsCreateRequestBody -Username 'dimilov' -Config $LocalAccountsConfig #Create Account Request Body

Invoke-CreateLocalAccounts -LocalAccountsCreateRequestBody $LocalAccountsCreateRequestBody #Create Local Account

Раздел документации vSphere API Documentation был существенно обновлен - туда были добавлены примеры, показывающие вызов REST API через PowerCLI. Например, вот раздел Create Local Accounts.

2. Новый vSphere Management Module

Для управления платформой vSphere теперь появился новый модуль. Это модуль на базе PowerShell, для построения которого используется архитектура модулей vSphere Automation API SDK, о которой рассказано выше. На данный момент в модуле 6 командлетов, позволяющих управлять сертификатами (по ссылкам вы можете почитать о них):

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

3. Прочие улучшения

Здесь были улучшены вот какие мелочи:

• Поддержка увеличенных параметров VMC SDDC
• Командлет Copy-DatastoreItem теперь поддерживает upload/download файлов VMDK с хранилищ vSAN
• API байндинги для VMware Horizon были обновлены, чтобы поддерживать все новые API решения Horizon 8.3 (он же 2106)

4. Новый логотип PowerCLI

Теперь он выглядит вот так:

Файлы ресурсов логотипа можно скачать тут.

Загрузить фреймворк VMware PowerCLI 12.4 можно по этой ссылке.

На сайте проекта VMware Labs очередная новая штука - vSphere Alert Center. Администраторы VMware vSphere часто настраивают алармы в vSphere Client, которые срабатывают при превышении некоторых критических порогов в виртуальной инфраструктуре. Эти алармы можно посмотреть в клиенте, но для них нельзя сделать прямые пуш-нотификации для администратора.

vSphere Alert Center работает в Windows, macOS и Linux (есть три отдельных дистрибутива). С помощью таких технологий, как Angular, Electron и vSphere.js компания VMware сделала утилиту, которая может соединяться с несколькими инстансами vCenter одновременно и показывать детальную информацию обо всех алармах.

Администратор может настроить интервал обработки алармов (по умолчанию - 5 минут), чтобы его не засыпало сообщениями.

Если какой-то из алармов требует внимания, то из приложения можно открыть vSphere Client, а исторические данные хранятся в локальном файле в зашифрованном виде.

Скачать vSphere Alert Center можно по этой ссылке.

Компания VMware к началу осени обновила один из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0, Update 2". Этот whitepaper не просто так называется книгой, так как данный документ представляет собой всеобъемлющее руководство почти на 100 страницах, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 Update 2 и виртуальных машин в контексте ее основных возможностей.

Глобальные разделы документа:

• Hardware for Use with VMware vSphere - о том, какое оборудование и как работает с платформой
• ESXi and Virtual Machines - об оптимизации хостов и ВМ на них
• Guest Operating Systems - об оптимизации непосредственно гостевых операционных систем
• Virtual Infrastructure Management - лучшие практики для средств управления виртуальной инфраструктурой

Ну а подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.

Очень полезное руководство для тех, кто хочет выжать из своей виртуальной среды максимум. Скачать книгу Performance Best Practices for VMware vSphere 7.0, Update 2 можно по этой ссылке.

В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:

• CVE-2021-21972 - VMSA-2021-0002 (плагин vRealize Operations Manager)
• CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
• CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)

Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.

В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:

Чтобы отключить сразу все указанные плагины, нужно будет добавить следующий текстовый блок:

<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>

<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>

<PluginPackage id="com.vmware.vrUi" status="incompatible"/>

<PluginPackage id="com.vmware.vum.client" status="incompatible"/>

<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>

Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):

Итак, чтобы отключить плагины, вам нужно:

• Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
• Сделать резервную копию файла, например, командой:
  cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
• Открыть этот файл в текстовом редакторе командой:
  vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
• Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):

• Сохранить файл с помощью команды vi:
  :wq!
• Перезапустить сервисы vsphere-ui:
  service-control --stop vsphere-ui
service-control --start vsphere-ui

Если вы все еще используете VMware vCenter for Windows, то указанную процедуру нужно проделать в следующем файле (не забывайте сделать его бэкап):

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

Делается это в том же месте, что и для матрицы совместимости в vCSA:

После этого также перезапускаем службу vsphere-ui для Windows:

C:\Program Files\VMware\vCenter Server\bin> service-control --stop vsphere-ui
C:\Program Files\VMware\vCenter Server\bin> service-control --start vsphere-ui

В том, что плагины отключены вы сможете убедиться в интерфейсе vSphere Client в разделе Administration > Solutions > client-plugins:

Ну и для тех, кому удобнее воспринимать руководство в видеоформате, компания VMware сделала ролик на эту тему:

Недавно компания VMware объявила о доступности для загрузки решения vRealize Automation 8.5 (vRA), предназначенного для автоматизации рутинных операций в облаке на базе VMware vSphere. Напомним, что о прошлой версии vRA мы писали вот тут.

Давайте посмотрим, что нового появилось в Automation 8.5:

1. Обновления поддержки Microsoft Azure

Здесь появились такие улучшения, как оптимальное использование availability sets, повторное использование групп ресурсов для day-2 хранилищ, поддержка кастомных образов в image gallery, поддержка disk encryption sets, включение/отключение диагностики загрузки и аналитики логов, ну и множество других небольших улучшений, о которых подробнее написано тут.

2. Поддержка новых окружений VMware Cloud

Теперь в рамках поддержки публичных облачных инфраструктур VMware обеспечивает работу решения vRA для облаков Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS) и VMware Cloud on Dell EMC.

3. Улучшения NSX-T Federation

Теперь механизм федерации позволяет выбрать локальный или глобальный NSX Manager в аккаунте NSX-T Cloud Account, а также существующие глобальные сегменты для вашего окружения. Кроме того, vRA поддерживает существующие Global Security Groups для профилей Network Profile или в рамках шаблонов Cloud Template.

Подробнее об этом функционале рассказано тут.

4. Улучшения назначения IP

Теперь vRA 8.5 имеет возможность назначить тот же самый диапазон IP-адресов для сетей vSphere и NSX. Например, это полезно, когда у вас есть несколько серверов vCenter, и вы хотите использовать один диапазон IP для нескольких сетей в рамках нескольких vCenter. Каждым таким окружением vRA будет управлять отдельно.

5. Механизм Custom Resource Action Troubleshooting

Теперь можно включить кастомный траблшутинг day-2 в vRA, привязать его к event ID troubleshooting и показывать пользователю результат выполнения рабочего процесса:

Теперь можно также создавать подписки на кастомные ресурсы (pre-and-post-event). Подробнее об это тут.

6. Квоты ресурсов

Теперь появилась новая политика Resource Quota Policy, которая позволяет облачным администраторам ограничить потребление ресурсов процессора, памяти и хранилища. Ограничения можно задавать на уровне организации, проекта или пользователя.

Более подробно об этом рассказано тут.

7. Интеграции с конфигурациями SaltStack

Теперь можно использовать свойство vRA Cloud Template saltConfiguration для установки объектов minions и файлов состояния в них во время развертывания.

Более детально об этом написано здесь.

8. Улучшения Property Group

Новые возможности Property Groups включают в себя действия vRO Actions для динамических внешних значений, что позволяет задать входные параметры Property Group. Теперь можно привязать пароли (secrets) к постоянным значениям Property Group и использовать их повторно. Также механизм RBAC позволяет создавать кастомные роли и контролировать Project Scope.

Подробнее обо всем этом вот тут.

9. vRealize Orchestrator Plugin для vRA

Теперь плагин vRO позволяет получить доступ к IaaS-объектам, таким как Cloud Zones, Cloud Accounts и Properties.

Более подробно об этом рассказано тут.

10. Представления Resource Views

Resource views - это новый способ мониторинга и управления ресурсами в vRA. Он позволяет:

• Выбрать тип управления - все ресурсы, либо по типам: машины, хранилища, сети
• Искать по имени ресурсов среди всех доступных ресурсов
• Получить простой доступ к day-2 actions прямо из контекстного меню ресурса
• Посмотреть, идет ли исполнение какого-либо действия day 2 action в данный момент

11. Поддержка Skyline

Эта поддержка включает в себя выработку рекомендаций для инстансов vRA, функции log assist для управления бандлами логов, а также отображение деталей об окружении vRA.

Подробнее об этом написано вот тут.

12. Управление нотификациями

Теперь можно включать и отключать нотификации для событий политик, включая события lease, approval и onboarding relocations. Сценарии нотификаций контролируются через службу Service Broker в vRA.

Скачать VMware vRealize Automation 8.5 можно по этой ссылке.

В начале лета компания VMware выпустила важный документ о сетевой безопасности своей виртуальной среды на базе решения NSX-T, который называется NSX-T Security Reference Guide.

Напомним, что решение VMware NSX-T - это продукт для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker.

Документ NSX-T Security Reference Guide представляет собой основное руководство по безопасному построению виртуального сетевого взаимодействия в рамках датацентра на базе платформы VMware vSphere. Основная цель этого руководства - рассказать пользователям NSX-T о лучших практиках построения защищенной сетевой среды, которая соответствует всем современным требованиям с точки зрения безопасности.

Давайте взглянем на основные главы документа:

• NSX Use cases/Customer journey/ Deployment options
• NSX-T Architecture Components
• Virtual Firewalling
• NSX Firewall Policy Building
• Container Security
• Firewall features
• Intrusion Detection and Prevention
• Federation
• Management and Operations

Документ полностью технический и очень детальный - занимает более 140 страниц, поэтому для всех глубоко интересующихся темой безопасности виртуальных сред на базе vSphere/NSX-T будет очень полезен.

Скачивайте!

Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.

Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.

Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

Высокая производительность и надежность решения достигается как за счет технологии NVMe, так и за счет отделения и изоляции сервисов резервного копирования от производственных данных. При этом сервисы бэкапа StarWind BA нагружают системные ресурсы только тогда, когда начинают выполнять задачу резервного копирования.

Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.

Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:

• Microsoft Hyper-V версий 2016, 2019 или 2022
• VMware vSphere версий 6.5, 6.7 или 7.0

На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):

Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.

В качестве протоколов доступа к данным поддерживаются следующие:

• iSCSI
• SMB3
• NFSv4.1
• NVMe-oF

Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.

Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.

Многим Enterprise-администраторам VMware vSphere знаком сервис VMware Skyline, который позволяет проактивно получать рекомендации по технической поддержке продуктов линейки VMware vSphere, включая vSAN.

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Если вы хотите спрятать некоторые советы и рекомендации, которые не требуют применения в вашей инфраструктуре, вы можете использовать специальные фильтры для вывода ненужных объектов. Например, можно спрятать Trivial Findings, которые не очень важны и только мешают увидеть серьезные проблемы.

Просто в левой панели выбираете нужный фильтр и нажимаете Hide Findings в разделе Active Findings:

Эти рекомендации не удаляются - их всегда можно увидеть на вкладке Hidden Findings (см. скриншот выше).

Далее спрятанные рекомендации можно экспортировать в CSV-файл, чтобы, например, обсудить их с командой техподдержки VMware или собственной командой:

Вторая полезная функция по сокрытию рекомендаций - это возможность исключить выбранные объекты из Inventory. Для этого в левой панели нужно раскрыть дерево объектов и снять галки с ненужных. Например, это могут быть давно списанные хосты ESXi или компоненты окружения разработки и тестирования:

Ну и чтобы посмотреть описанное в действии, можете взглянуть на это видео:

Компания VMware уже несколько недель назад сделала доступным каталог сессий предстоящего VMworld 2021. Некоторое время назад мы уже писали про изменения, которые произойдут в онлайн-конференции, а сегодня немного расскажем о самом каталоге будущих выступлений.

Сейчас в списке 850 сессий (может быть, будет больше), искать можно как по ключевым словам, так и по различным аспектам докладов (для кого они, о каких продуктах, уровень сложности материала и прочее).

А вот список самого интересного от Дункана Эппинга - глубокие технические сессии от известных блоггеров и сотрудников VMware:

• Project Monterey: Present, Future and Beyond [MCL1401] by Sudhanshu Jain and Simer Singh
  
• What Is the Future of Cloud and On-Premises Storage and Availability? [MCL2590]
• Make Sustainable Choices for Product Innovation, Operations: What Can I Do? [IC2794]
• Core Storage Best Practices Deep Dive [MCL2071]
  
• Security Deep Dive and Emerging Capabilities in VMware Cloud on AWS [SEC1362]
• VEBA Revolutions – Unleashing the Power of Event-Driven Automation [CODE2773]
• VDI Nerdfest 2021: Demos That Make Admins Drool [EUS1289]
  
• Extreme Performance Series: Performance best practices [MCL1635]
• 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
• Best Practices for Running AI Workloads in VMs on VMware vSphere [VI1459]
• The Future of VM Provisioning – Enabling VM Lifecycle Through Kubernetes [APP1564]
• The Evolution of Intelligent Edge and Electrical Grid Modernization [VI1455]
• Upskill Your Workforce with Augmented and Virtual Reality and VMware [VI1596]
• Automating Ransomware Remediation with the VMware Carbon Black Cloud SDK [CODE2782]
• Migration in Action with Google Cloud VMware Engine [MCL1764]

В общем, в начале октября будет точно что посмотреть и послушать!

На сайте проекта VMware Labs появилась очередная полезная штуковина - OpenAPI interface for vSphere. Это новый протокол, который является альтернативой SOAP/XML, позволяющий получать доступ к интерфейсам управления VMware vSphere через обмен в JSON-формате. Работа с этим API происходит на базе открытой спецификации OpenAPI.

С помощью OpenAPI interface for vSphere можно получить следующие преимущества:

• Приложения, которые используют REST API и традиционные vSphere Client API могут перейти на один протокол обмена, а значит не нужно поддерживать 2 интерфейса
• Партнеры могут разрабатывать различные дополнения и утилиты для VMware vSphere на базе открытых спецификаций
• Существующие API можно расширять, добавляя новые возможности как в стандартную модель SOAP/XML, так и в новый протокол
• Новый протокол не зависит от существующих API, поэтому не требует доработки сервисов на бэкенде, что ускоряет его внедрение

Новый OpenAPI interface доступен как для написания комплексных независимых сценариев (например, с помощью curl или Postman) в целях автоматизации рутинных задач, так и разработки различных дополнений и компонентов с помощью специального SDK, который будет доступен партнерам VMware.

Разработчикам сценариев также доступны примеры работы простых функций в виде шаблонов, которые можно кастомизировать через CLI-интерфейс. Для работы с OpenAPI вам понадобится:

• vSphere 7.0 или свежее
• Окружение Docker или Kubernetes
• JDK 8 или свежее
• 8 GB RAM

Загрузить компоненты OpenAPI interface for vSphere можно по этой ссылке.

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

Находим там группу ServiceProviderUsers на второй странице и добавляем туда пользователей, которым мы хотим дать разрешение на просмотр неймспейсов:

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

Cormac Hogan, известный специалист в области виртуальных хранилищ на платформе VMware vSphere, выпустил интересное видео об использовании постоянных томов (Persistent Volumes) в качестве файловых шар для кластеров Kubernetes:

В качестве бэкенда таких томов используются файловые шары кластеров VMware vSAN, которые позволяют администраторам Kubernetes контролировать их использование со стороны инфраструктуры контейнеризованных приложений. В видео рассказано о том, как предоставлять права доступа (read only, read/write) на базе параметров сетей, которые получают доступ к томам. Также у Кормака есть детальная статья о том, как эти права доступа настраивать.

Из видео вы узнаете, как шаг за шагом настраивать доступ к томам через конфигурационный файл CSI-драйвера и контролировать сетевой доступ в томам через службы vSAN File Services.

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим...

Некоторое время назад мы писали о First-Class Disks (FCD), которые были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes.

При создании профиля хранилищ вы можете указать тип диска как FCD:

В VMware vSphere 7 Update 2 для FCD появилась поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

В VMware vRealize Automation версии 8.2 появилась поддержка First-Class Disks (FCD), что открывает большие возможности по автоматизации операций при управлении такими хранилищами. Это функции улучшаются с каждым релизом vRA.

Eric Sloof написал небольшую заметку об использовании таких дисков с vRealize Automation. Одно из преимуществ дисков FCD - это возможность создавать их снапшоты независимо от каких-либо виртуальных машин.

При создании и редактировании описания профиля хранилищ в VMware vRealize Automation вы можете указать поддержку в дисков FCD или обычных дисков в storage profile:

Также через API в vRealize Automation вы можете получить доступ к операциям Create, Edit, Delete и List для таких дисков. Также в рамках рабочих процессов в Automation доступны и day-2 операции, такие как добавление диска, привязка/отвязывание и изменение размера.

Для снапшотов диска также доступны операции управления их жизненным циклом. Так что администраторы теперь могут придумывать и автоматизировать рабочие процессы с постоянными виртуальными дисками FCD для самых разных задач.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

Как видно из картинки выше, в этом сообщении поддерживаются специальные символы и эмоджи. Вот так это будет выглядеть для пользователей:

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.UpdateServiceMessage($motd)

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

Не все администраторы VMware vSphere знают, что у VMware есть очень полезный ресурс Ports and Protocols, где можно посмотреть актуальные порты и протоколы, которые используются различными продуктами. Мы писали об этом сайте в 2019 году, с тех пор он существенно обновился, и теперь там есть информация по портам и соединениям практически для всех продуктов.

Во-первых, в колонке слева теперь доступна информация не по 12 продуктам, как раньше, а по 34, среди которых есть и относительно новые, такие как Tanzu Kubernetes Grid и Lifecycle Manager:

Во-вторых, в верхней части страницы появилась вкладка «Network Diagrams», где собраны несколько сетевых диаграмм, наглядно показывающих соединения между различными компонентами продуктов:

Пока таких диаграмм немного, но список решений будет пополняться.

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

В случае с отказом Primary хоста все немного дольше и сложнее, так как кластеру нужно определиться с новым Primary узлом и восстановить/перенастроить себя. Тут происходит следующее:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

Надо помнить, что это все времена начала процессов, но не их завершения. Например, если процесс восстановления начинается через 15 секунд, то нужно время, чтобы найти место для виртуальной машины на новом хосте и запустить ее там – а вот это время рассчитать невозможно.

Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.

Дункан Эппинг показал на примере виртуального коммутатора vSwitch, как можно работать с configstore и хранящимися там настройками. Например, вам требуется сменить имя виртуального коммутатора. Вы можете посмотреть его текущие сетевые настройки командой:

configstorecli config current get -c esx -g network_vss -k switches

Ну а экспортировать эти настройки в JSON-файл можно командой:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:

Потом получившийся файл нужно обратно импортировать в configstore:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

После этого вы увидите изменения в vSphere Client:

Также Дункан записал видео, в котором показан этот процесс:

После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. Выбор профилей для MIG-режима выглядит так:

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

Мы несколько раз писали об онлайн-сервисе VMware vSphere DRS Dump Insight, который позволяет показывать различную информацию по перемещению виртуальных машин в кластере DRS на портале самообслуживания, куда пользователи могут загружать файлы дампов.

Это позволяет вам получить ответы на следующие вопросы:

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

На днях у VMware вышло руководство пользователя по этой утилите, которое будет интересно почитать всем администраторам кластеров VMware DRS, решившим начать анализировать дампы DRS:

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui